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Abstract —E-voting systems have emerged as a powerful tech¬ 
nology for improving democracy hy reducing election cost, in¬ 
creasing voter participation, and even allowing voters to directly 
verify the entire election procedure. Prior internet voting systems 
have single points of failure, which may result in the compromise 
of availability, voter secrecy, or integrity of the election results. 

In this paper, we present the design, implementation, security 
analysis, and evaluation of D-DEMOS, a complete e-voting system 
that is distributed, privacy-preserving and end-to-end verifiable. 
Our system includes a fully asynchronous vote collection subsys¬ 
tem that provides immediate assurance to the voter her vote was 
recorded as cast, without requiring cryptographic operations on 
behalf of the voter. We also include a distributed, replicated and 
fault-tolerant Bulletin Board component, that stores all necessary 
election-related information, and allows any party to read and 
verify the complete election process. Einally, we also Incorporate 
trustees, i.e., individuals who control election result production 
while guaranteeing privacy and end-to-end-verifiability as long 
as their strong majority is honest. 

Our system is the first e-voting system whose voting operation 
is human verifiable, i.e., a voter can vote over the web, even when 
her web client stack is potentially unsafe, without sacrificing 
her privacy, and still be assured her vote was recorded as cast. 
Additionally, a voter can outsource election auditing to third 
parties, still without sacrificing privacy. Einally, as the number 
of auditors increases, the probability of election fraud going 
undetected is diminished exponentially. 

We provide a model and security analysis of the system. We 
implement a prototype of the complete system, we measure its 
performance experimentally, and we demonstrate its ability to 
handle large-scale elections. 

I. Introduction 

E-voting systems have emerged as a powerful technology to 
improve the election process. Kiosk-based e-voting systems, 
e.g., [12], [15], [25], [13], [10], [22] allow the tally to be 
produced faster, but require the voter’s physical presence at 
the booth. Internet e-voting systems, e.g., [20], [8], [16], [30], 
[26], [33], [12], [13], [33], [28], however, allow voters to cast 
their votes remotely. Internet voting systems have the potential 
to improve the democratic process by reducing election costs 
and by increasing voter participation for social groups that 
face considerable physical barriers and overseas voters. In 
addition, several internet voting systems [8], [30], [33], [28] 
allow voters and auditors to directly verify the integrity of the 
entire election process, providing end-to-end verifiability. This 
is a highly desired property that has emerged in the last decade, 
where voters can be assured that no entities, even the election 


authorities, have manipulated the election result. Despite their 
potential, existing internet voting systems suffer from single 
points of failure, which may result in the compromise of voter 
secrecy, service availability, or integrity of the result [12], [15], 
[25], [13], [10], [20], [8], [16], [30], [26], [33], [28]. 

In this paper, we present the design and prototype imple¬ 
mentation of D-DEMOS, a distributed, end-to-end verifiable 
internet voting system, with no single point of failure during 
the election process (that is, besides setup). We set out to over¬ 
come two major limitations in existing internet voting systems. 
The first, is their dependency on centralized components. The 
second is their requirement for the voter to run special software 
on their devices, which processes cryptographic operations. 
Overcoming the latter allows votes to be cast with a greater 
variety of client devices, such as feature phones using SMS, or 
untrusted public web terminals. Our design is inspired by the 
novel approach proposed in [28], where the voters are used 
as a source of randomness to challenge the zero-knowledge 
protocols, which are used to enable end-to-end verifiability. 

We design a distributed vote collection subsystem that is 
able to collect votes from voters and assure them their vote 
was recorded as cast, without requiring any cryptographic 
operation from the client device. This allows voters to vote 
via SMS, a simple console client over a telnet session, or 
a public web terminal, while preserving their privacy. At 
election end time, vote collectors agree on a single set of 
votes asynchronously, and upload it to a second distributed 
component, the Bulletin Board. This is a replicated service 
that publishes its data immediately and makes it available to 
the public forever. Our third distributed subsystem, trustees 
are a set of persons entrusted with secret keys that can unlock 
information from the bulletin board. We share these secret keys 
among them, making sure that an honest majority is required 
to uncover information from the BB. Trustees interact with the 
BB once the votes are uploaded to it, to produce and publish 
the final election tally. 

The resulting voting system is end-to-end verifiable, by 
the voters themselves, as well as third-party auditors; all 
this while preserving voter privacy. A voter can provide an 
auditor information from her ballot; the auditor can read 
from the distributed BB and verify the complete process, 
including the correctness of the election setup by election 
authorities. Additionally, as the number of auditors increases. 



the probability of election fraud going undetected diminishes 
exponentially. 

Finally, we implement a prototype of the complete D- 
DEMOS voting system. We measure its performance exper¬ 
imentally, under a variety of election settings, demonstrating 
its ability to handle thousands of concurrent connections, and 
thus manage large-scale elections. 

To summarize, we make the following contributions: 

• We present the world’s first complete, state-of-the-art, 
end-to-end verifiable, distributed voting system with no 
single point of failure besides setup. 

• The system allows voters to verify their vote was tallied- 
as-intended without the assistance of special software 
or trusted devices, and external auditors to verify the 
correctness of the election process. Additionally, the 
system allows voters to delegate auditing to a third party 
auditor, without sacrificing their privacy. 

• We provide a model and a security analysis of our voting 
system. 

• We implement a prototype of the integrated system, 
measure its performance and demonstrate its ability to 
handle large scale elections. 

II. Related work 

Voting systems. Several end-to-end verifiable e-voting sys¬ 
tems have been introduced, e.g. the kiosk-based systems [15], 
[25], [13], [10] and the internet voting systems [8], [30], [33], 
[28]. In all these works, the Bulletin Board (BB) is a single 
point of failure and has to be trusted. 

Dini presents a distributed e-voting system, which however 
is not end-to-end verifiable [23]. In [22], there is a distributed 
BB implementation, also handling vote collection, according 
to the design of the vVote end-to-end verifiable e-voting 
system [21], which in turn is an adaptation of the Pret a Voter 
e-voting system [15]. In [22], the proper operation of the BB 
during ballot casting requires a trusted device for signature 
verification. In contrast, our vote collection subsystem is done 
so that correct execution of ballot casting can be “human 
verifiable”, i.e., by simply checking the validity of the obtained 
receipt. Additionally, our vote collection subsystem is fully 
asynchronous, always deciding with exactly n—f inputs, while 
in [22], the system uses a synchronous approach based on the 
FloodSet algorithm from [31] to agree on a single version of 
the state. 

DEMOS [28] is an end-to-end verifiable e-voting system, 
which introduces the novel idea of extracting the challenge of 
the zero-knowledge proof protocols from the voters’ random 
choices; we leverage this idea in our system too. However, 
DEMOS uses a centralized Election Authority (EA), which 
maintains all secrets throughout the entire election procedure, 
collects votes, produces the result and commits to verification 
data in the BB. Hence, the EA is a single point of failure, 
and because it knows the voters’ votes, it is also a critical 
privacy vulnerability. In this work, we address these issues 
by introducing distributed components for vote collection and 
result tabulation, and we do not assume any trusted component 


during election. Additionally, DEMOS does not provide any 
recorded-as-cast feedback to the voter, whereas our system 
includes such a mechanism. Besides, DEMOS encodes the i- 
th option to where N is greater than the total number of 

voters, and this option encoding has to fit in the message space 
of commitments. Therefore, the size of the underlying elliptic 
curve grows linearly with the number of options, which makes 
DEMOS not scalable with respect to the number of options. 
In this work, we overcome this problem by using a different 
scheme for option encoding commitments. Moreover, the zero- 
knowledge proofs in DEMOS have a big soundness error, and 
it decreases the effectiveness of zero-knowledge application; 
whereas, in our work, we obtain nearly optimal overall zero- 
knowledge soundness. 

Furthermore, none of the above works provide any perfor¬ 
mance evaluation results. 

State Machine Replication. Castro et al. [11] introduce a 
practical Byzantine Fault Tolerant replicated state machine 
protocol. In the last several years, several protocols for 
Byzantine Fault Tolerant state machine replication have been 
introduced to improve performance ([19], [29]), robustness 
([9], [18]), or both ([17]). Our system does not use the state 
machine replication approach, as it would be more costly. Each 
of our vote collection nodes can validate the voter’s requests 
on its own. In addition, we are able to process multiple 
different voters’ requests concurrently, without enforcing the 
total ordering inherent in replicated state machines. Finally, 
we do not want voters to use special client-side software to 
access our system. 

HI. System description 

A. Problem definition and goals 

We consider an election with a single question and m 
options, for a voter population of size n, where voting takes 
place between a certain begin and end time (the voting hours), 
and each voter may select a single option. 

Our major goals in designing our voting system are three. 
First, it has to be end-to-end verifiable, so that anyone can ver¬ 
ify the complete election process. Additionally, voters should 
be able to outsource auditing to third parties, without revealing 
their voting choice. Second, it has to be fault-tolerant, so that 
an attack on system availability and correctness is hard. Third, 
voters should not have to trust the terminals they use to vote, 
as they may be malicious; voters should be assured their vote 
was recorded, without disclosing any information on how they 
voted to the malicious entity controlling their device. 

B. System overview 

We employ an election setup component in our system, 
which we call the Election Authority (EA), to alleviate the 
voter from employing any cryptographic operations. The EA 
is tasked to initialize all remaining system components, and 
then gets destroyed to preserve privacy. The Vote Collection 
(VC) subsystem collects the votes from the voters during 
election hours, and assures them their vote was recorded-as- 
cast. Our Bulletin Board (BB) subsystem, which is a public 
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repository of all election related information, is used to hold 
all ballots, votes, and the result, either in encrypted on plain 
form, allowing any party to read from it and verify the 
complete election process. The VC subsystem uploads all 
votes to BB at election end time. Finally, our design includes 
trustees, who are persons entrusted with managing all actions 
needed until result tabulation and publication, including all 
actions supporting end-to-end verifiability. Trustees hold the 
keys to uncover any information hidden in the BB, and we 
use threshold cryptography to make sure a malicious minority 
cannot uncover any secrets or corrupt the process. 

Our system starts with the EA generating initialization data 
for every component of our system. The EA encodes each 
election option, and commits to it using a commitment scheme, 
as described below. It encodes the z-th option as ez, a unit 
vector where the z-th element is 1 and the remaining elements 
are 0. The commitment of an option encoding is a vector 
of (lifted) ElGamal ciphertexts [24] over elliptic curve, that 
element-wise encrypts a unit vector. Note that this commitment 
scheme is also additively homomorphic, i.e. the commitment 
of Ca + Cb can be computed by component-wise multiplying 
the corresponding commitments of Ca and Cb- The EA then 
creates a votecode and a receipt for each option. Then, the 
EA prepares one ballot for each voter, with two functionally 
equivalent parts. Each part contains a list of options, along 
with their corresponding vote codes and receipts. We consider 
ballot distribution to be outside the scope of this project, but 
we do assume ballots, after being produced by the EA, are 
distributed in a secure manner to each voter; thus only each 
voter knows the vote codes listed in her ballot. We make sure 
vote codes are not stored in clear form anywhere besides the 
voter’s ballot. 

Our Vote Collection (VC) subsystem collects the votes from 
the voters during election hours, by accepting up to one vote 
code from each voter. Our EA initializes each VC node with 
the vote codes and the receipts of the voters’ ballots. However, 
it hides the vote codes, using a simple commitment scheme 
based on symmetric encryption of the plaintext along with 
a random salt value. This way, each VC node can verify if a 
vote code is indeed part of a specific ballot, but cannot recover 
any vote code until the voter actually chooses to disclose it. 
Additionally, we secret-share each receipt across all VC-nodes 
using a {N — f,N)-'VSS scheme with trusted dealer, making 
sure that a receipt can be recovered and posted back to the 
voter only when a strong majority of VC nodes participates 
successfully in our voting protocol. With this design, our 
system adheres to the following contract with the voters; Any 
honest voter who receives a valid receipt from a Vote Collector 
node, is assured her vote will be published on the BB, and thus 
included in the election tally. 

The voter selects one part of her ballot at random, and posts 
her selected vote code to one of the VC nodes. When she 
receives a receipt, she compares it with the one on her ballot 
corresponding to the selected vote code. If it matches, she is 
assured her vote was recorded and will be included in the 
election tally. The other part of her ballot, the one not used 


for voting, will be used for auditing purposes. This design 
is essential for verifiability, in the sense that the EA cannot 
predict which part a voter may use, and the unused part will 
betray a malicious EA with 1/2 probability per audited ballot. 

Our second distributed subsystem is the Bulletin Board 
(BB), which is a replicated service of isolated nodes. Each BB 
node is initialized from the EA with vote codes and associated 
option encodings in committed form (again, for vote code 
secrecy), and each BB node provides public access to its stored 
information. On election end time, VC nodes run our Vote Set 
Consensus protocol, which guarantees all VC nodes agree on 
a single set of voted (serial-no, vote-code) tuples. Then, VC 
nodes upload this set to each BB node, which in turn publishes 
this set once enough VC nodes provide the same set. 

Our third distributed subsystem is a set of trustees, who are 
persons entrusted with managing all actions needed until result 
tabulation and publication, including all actions supporting 
end-to-end verifiability. Secrets that may uncover information 
in the BB are shared across trustees, making sure malicious 
trustees under a certain threshold cannot disclose sensitive in¬ 
formation. We use Pedersen’s Verifiable linear Secret Sharing 
(VSS) [32] to split the election data among the trustees. In a 
(fc,rz)-VSS, at least k shares are required to reconstruct the 
original data, and any collection of less than k shares leaks no 
information about the original data. Moreover, Pedersen’s VSS 
is additively homomorphic, i.e. one can compute the share of 
a -I- 6 by adding the share of a and the share of b respectively. 
Using this scheme allows trustees to perform homomorphic 
“addition” on the option-encodings of cast vote codes, and 
contribute back a share of the opening of the homomorphic 
“total”. Once enough trustees upload their shares of the “total”, 
the election tally is uncovered and published at each BB node. 

Note that, to ensure voter privacy, the system cannot reveal 
the content inside an option encoding commitment at any 
point. However, a malicious EA might put an arbitrary value 
(say 9000 votes for option 1) inside such a commitment, 
causing an incorrect tally result. To prevent this, we utilize 
the Chaum-Pedersen zero-knowledge proof [14], allowing the 
EA to show that the content inside each commitment is a 
valid option encoding, without revealing its actual content. 
Namely, the prover uses Sigma OR proof to show that each 
ElGamal ciphertext encrypts either 0 or 1, and the sum of 
all elements in a vector is 1. Our zero knowledge proof is 
organized as follows. Eirst, the EA posts the initial part of 
the proofs on the BB. During the election, each voter’s A/B 
part choice is viewed as a source of randomness, 0/1, and all 
the voters’ coins are collected and used as the challenge of 
our zero knowledge proof. After that, the trustees will jointly 
produce the final part of the proofs and post it on the BB 
before the opening of the tally. Hence, everyone can verify 
those proofs on the BB. Eor notation simplicity, we omit the 
zero-knowledge proof components in this paper and refer the 
interested reader to [14] for details. 

Due to this design, any voter can read information from the 
BB, combine it with her private ballot, and verify her ballot 
was included in the tally. Additionally, any third-party can 
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read the BB and verify the complete election process. As the 
number of auditors increases, the probability of election fraud 
going undetected diminishes exponentially. For example, even 
if only 10 people audit, with each one having i probability 
to detect ballot fraud, the probability of ballot fraud going 
undetected is only i = 0.00097. Thus, even if the EA is 
malicious and, e.g., tries to point all vote codes to a specific 
option, this faulty setup will be detected because of the end- 
to-end verifiability of the complete system. 

C. System and threat model 

We assume a fully connected network, where each node can 
reach any other node with which it needs to communicate. 
The network can drop, delay, duplicate, or deliver messages 
out of order. However, we assume messages are eventually 
delivered, provided the sender keeps retransmitting them. 
For all nodes, we make no assumptions regarding processor 
speeds. We assume the clocks of VC nodes are synchronized 
with real time; this is needed simply to prohibit voters from 
casting votes outside election hours. Besides this, we make 
no other timing assumptions in our system. We assume the 
EA sets up the election and is destroyed upon completion of 
the setup, as it does not directly interact with the remaining 
components of the system, thus reducing the attack surface for 
the privacy of the voting system as a whole.We also assume 
initialization data for every system component is relayed to 
it via untappable channels. We assume the adversary does 
not have the computational power to violate any underlying 
cryptographic assumptions. To ensure liveness, we additionally 
assume the adversary cannot delay communication between 
honest nodes above a certain threshold. We place no bound 
on the number of faulty nodes the adversary can coordinate, 
as long as the number of malicious nodes of each subsystem is 
below its corresponding fault threshold. We consider arbitrary 
(Byzantine) failures, because we expect our system to be 
deployed across separate administrative domains. 

Let Ny, Ny, and Nt be the number of VC nodes, BB nodes, 
and trustees respectively. The voters are denoted hy Vg, I = 
1,... ,n. We assume that there exists a global clock variable 
Clock € N, and that every VC node, BB node and voter X is 
equipped with an internal clock variable Clock[A'] G N. We 
define the two following events on the clocks: 

(i) . The event Init(X) : Clock[X] ■<— Clock, that initializes 

a node X by synchronizing its internal clock with the 
global clock. 

(ii) . The event Inc(i) : * i -f 1, that causes some clock i 

to advance by one time unit. 

All system particpants are aware of a value Tend such that 
for each node X, if Clock[X] > Tend, then X considers that 
the election has ended. 

The adversarial setting for A upon D-DEMOS is defined 
in Figure 1. The description in Figure 1 poses no restrictions 
on the control the adversary has over all internal clocks, or 
the number of nodes that it may corrupt (arbitrary denial of 
service attacks or full corruption of D-DEMOS nodes are 
possible). Therefore, it is necessary to strengthen the model 


The adversarial setting. 

1) The EA initializes every VC node,BB node, trustee of 
the D-DEMOS system by running Init(-) in all clocks 
for synchronization. Then, EA prepares the voters’ 
ballots and all the VC nodes’, BB nodes’, and trustees’ 
initialization data. Finally, it forwards the ballots for 
ballot distribution to the voters Vi, ^ = 1,... ,n. 

2) A corrupts a fixed subset of VC nodes, a fixed subset 
of BB nodes, and a fixed subset of trustees. In addition, 
it defines a dynamically updated subset of voters Vcorr, 
initially set as empty. 

3) When an honest node X wants to transmit a message 
M to an honest node Y, then it just sends (X, M, Y) 
to A. 

4) A may arbitrarily invoke the events Inc(Clock) or 
lnc(Clock[X]), for any node X. Moreover, A may 
write on the incoming network tape of any honest 
component node of D-DEMOS. 

5) For every voter V), A can choose whether it is going 
to include Vi in Vcorr- 

(i) . If Ve G Vcorr, then A fully controls 14- 

(ii) . If ^ Vcorr, then A may initialize Vi by 

running lnit(V£) only once. If this happens, then 
the only control of A over Vn is lnc(Clock[Vf]) 
invocations. Upon initialization, engages in 
the voting protocol. 


Figure 1. The adversarial setting for the adversary A acting upon the 
distributed bulletin board system. 

so that we can perform a meaningful security analysis and 
prove the properties (liveness, safety, end-to-end verifability, 
and voter privacy) that D-DEMOS achieves in Section IV. 
Namely, we require the following: 

7) Fault tolerance: We consider arbitrary (Byzantine) fail¬ 
ures. For each of the subsystems, we have the following fault 
tolerance thresholds: 

Let Ny, Ny, and Nt be the number of VC nodes, BB nodes, 
and trustees respectively. The voters are denoted by 14, 7 = 
1,... ,n. For each of the subsystems, we have the following 
fault tolerance thresholds: 

■ The number of faulty VC nodes, fy, is strictly less than 
1/3 of Ny, i.e., for fixed /„: 

Nv ^ 3/« -f 1. 

• The number of faulty BB nodes, /{,, is strictly less than 
1/2 of Ny, i.e., for fixed /{,: 

Nb > 2fb + 1 . 

• For the trustees’ subsystem, we apply ht out-of Nt 
threshold secret sharing, where ht is the number of honest 
trustees, thus we tolerate ft = Nt — ht malicious trustees. 
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2) Liveness assumptions: Only for the liveness of our 
system, we need to ensure eventual message delivery and 
bounded synchronization loss. Therefore, it is necessary, to 
make the following assumptions: 

Assumption I: There exists an upper bound S on the time 
that A can delay the delivery of the messages between honest 
nodes. Formally, when the honest node X sends (A, M, Y) 
to A, if the value of the global clock is T, then A must 
write M on the incoming network tape of Y by the time that 
Clock = r + ,5. 

Assumption II: There exists an upper bound A of the drift 
of all honest nodes’ internal clocks with respect to the global 
clock. Formally, we have that: |Clock[A] — Clockj < A for 
every node X, where | • | denotes the absolute value. 

D. Election Authority 

EA produces the initialization data for each election entity 
in the setup phase. To enhance the system robustness, we let 
the EA generate all the public/private key pairs for all the 
system components (except voters) without relying on external 
PKI support. We use zero knowledge proofs to ensure the 
correctness of all the initialization data produced by the EA. 

Voter ballots. The EA generates one ballot ballot^ for each 
voter and assigns a unique 64-bit serial-no^ to it. As shown 
below, each ballot consists of two parts: A and B. Each part 
contains a list of m (vote-code, option, receipt) tuples, one 
tuple for each election option. The EA generates the vote- 
code as a 160-bit random number, unique within the ballot, 
and the receipt as 64-bit random number. 


serial-no^ 

vote-codef,i 

Part A 
option^ 1 

receipt^ ^ 

vote-codef,m 


receipt^,„ 

vote-code^_i 

Part B 
option^ ^ 

receipt^^;^ 

vote-codef,m 

option^^ 

receipt^ 


BB initialization data. The initialization data for all BB 
nodes is identical, and each BB node publishes its initializa¬ 
tion data immediately. The BB’s data is used to show the 
correspondence between the vote codes and their associated 
cryptographic payload. This payload comprises the committed 
option encodings, and their respective zero knowledge proofs 
of valid encoding (hrst move of the prover), as described 
in section III-B. However, the vote codes must be kept 
secret during the election, to prevent the adversary from 
“stealing” the voters’ ballots and using the stolen vote codes 
to vote. To achieve this, the EA hrst randomly picks a 
128-bit key, msk, and encrypts each vote-code using AES- 
128-CBC with random initialization vector (AES-128-CBC$) 
encryption, denoted as [vote-code]msk- Each BB is given 
-ffmsk ^ 5'iTA256(msk, saltmsk) and saltmsk, where saltmsk 
is a fresh 64-bit random salt. Hence, each BB node can be 


assured the key it reconstructs from VC key-shares (see below) 
is indeed the key that was used to encrypt these vote-codes. 

The rest of the BB initialization data is as follows: for 
each serial-nof, and for each ballot part, there is a shuffled 
list of ^[vote-code^ (j)]msk, payload^ tuples, where 

irf G S*!, is a random permutation (X is A or B). 



serial-no^ 

[vOtG-COde^ 

Part A 
payload^ 

[vote-code^ A 

payload^^A(^) 

[vote-code^ msk 

Part B 

payload^_^B(i) 

[vote-code^ msk 

payload^ ,,B(^) 


We shuffle the list of tuples of each part to ensure voter’s 
privacy. This way, nobody can guess the voter’s choice from 
the position of the cast vote-code in this list. 

VC initialization data. The EA uses an (A„ — fv,Ny)- 
VSS to split msk and every receipt^ j, denoted 
as (||msk||i,..., ||msk||wj and (jjreceipt^j ||i,..., 
[[receipt^ jIIat,,). Eor each vote-code^j- in each ballot, the EA 
also computes H^ j 5'iJA256(vote-code£_j,salt^ j), where 
salt^j is a 64-bit random number. Hgj allows each VC 
node to validate a vote-code^j individually (without network 
communication), while still keeping the vote-code^j secret. 
To preserve voter privacy, these tuples are also shuffled using 
Trf. The initialization data for VCi is structured as below: 


||msk||i 

serial-no£ 


Part A 

l|receipt^_^A(i)||i 


IIreceipt^ 

(i)Aalt^_,rf (1)) 

Part B 

l|i'eceipt^_^B(i)||, 

(m) I sa ) 

||receipt^_^B(„Ji 


Trustee initialization data. The EA uses {ht, Nt)-WSS to 
split the opening of encoded option commitments Com(ei), 
denoted as ([e^ ^,..., [e^ ^ ). The initialization data for 
Trustee^ is structured as below: 
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serial-no^ 

Com(e,,A(,)) 

Part A 

e 

Com (4b (i)) 

Part B 

e 


Similarly, the state of zero knowledge proofs for ballot 
correctness is shared among the trustees using (/ij, A^t)-VSS. 
Due to space limitation, we omit the detailed description here 
and refer the reader to [14]. 

E. Vote Collectors 

VC is a distributed system of 7V„ nodes, running our 
voting and vote-set consensus protocols. VC nodes have pri¬ 
vate and authenticated channels to each other, and a public 
(unsecured) channel for voters. The algorithms implement¬ 
ing our voting protocol are presented in Algorithm 1. For 
simplicity, we present our algorithms operating for a single 
election. The voting protocol starts when a voter submits 
a VOTE(serial-no, vote-code) message to a VC node. We 
call this node the responder, as it is responsible for deliv¬ 
ering the receipt to the voter. The VC node conhrms the 
current system time is within the dehned election hours, 
and locates the ballot with the specihed serial-no. It also 
verihes this ballot has not been used for this election, 
either with the same or a different vote code. Then, it 
compares the vote-code against every hashed vote code in 
each ballot line, until it locates the correct entry. At this 
point, it multicasts an ENDORSE(serial-no, vote-code) mes¬ 
sage to all VC nodes. Each VC node, after making sure 
it has not endorsed another vote code for this ballot, re¬ 
sponds with an ENDORSEMENT(serial-no, vote-code,sigvCi) 

message, where sigvCi is a digital signature of the spe- 
cihc serial-no and vote-code, with VCi’s private key. The 
responder collects Ny — /„ valid signatures and forms a 
uniqueness certihcate UCERT for this ballot. It then ob¬ 
tains, from its local database, the receipt-share correspond¬ 
ing to the specihc vote-code. Then, it marks the ballot as 
pending for the specihc vote-code. Einally, it multicasts 
a VOTE_P(serial-no, vote-code, receipt-share, UCERT) mes¬ 
sage to all VC nodes, disclosing its share of the receipt. In 
case the located ballot is marked as voted for the specihc 
vote-code, the VC node sends the stored receipt to the voter 
without any further interaction with other VC nodes. 

Each VC node that receives a VOTE_P message, hrst 
verihes the validity of UCERT, and validates the received 
receipt-share according to the verihable secret sharing scheme 
used. Then, it performs the same validations as the responder, 
and multicasts another VOTE_P message (only once), disclos¬ 
ing its share of the receipt. When a node collects hy = Ny — fy 
valid shares, it uses the verihable secret sharing reconstruction 
algorithm to reconstruct the receipt (the secret) and marks the 
ballot as voted for the specihc vote-code. Additionally, the 
responder node sends this receipt back to the voter. 


The formation of a valid UCERT gives our algorithms the 
following guarantees: 

a) No matter how many responders and vote codes are active 
at the same time for the same ballot, if a UCERT is formed 
for vote code vca, no other uniqueness certihcate for any 
vote code different than vCa can be formed. 

b) By verifying the UCERT before disclosing a VC node’s 
receipt share, we guarantee the voter’s receipt cannot be 
reconstructed unless a valid UCERT is present. 

At election end time, each VC node stops processing EN¬ 
DORSE, ENDORSEMENT, VOTE and VOTE_P messages, 
and follows the vote-set consensus protocol, by performing 
the following steps for each registered ballot: 

1) Send ANNOUNCE(serial-no, vote-code, UCERT) to all 
nodes. The vote-code will be null if the node knows of 
no vote code for this ballot. 

2) Wait for Ny — fy such messages. If any of these messages 
contains a valid vote code vCa, accompanied by a valid 
UCERT, change the local state immediately, by setting 
vCa as the vote code used for this ballot. 

3) Participate in a Binary Consensus protocol, with the 
subject “Is there a valid vote code for this ballot?”. Enter 
with an opinion of 1, if a valid vote code is locally known, 
or a 0 otherwise. 

4) If the result of Binary Consensus is 0, consider the ballot 
not voted. 

5) Else, if the result of Binary Consensus is 1, consider the 
ballot voted. There are two sub-cases here: 

a) If vote code vCa, accompanied by a valid UCERT is 
locally known, consider the ballot voted for vCa- 

b) If, however, vCa is not known, send a RECOVER- 

REQUEST(serial-no) message to all VC 
nodes, wait for the hrst valid RECOVER- 
RESPONSE(serial-no, riCa, UCERT) response, 

and update the local state accordingly. 

Steps IV-B-2 ensure used vote codes are dispersed across 
nodes. Recall our receipt generation requires Ny — fy shares 
to be revealed by distinct VC nodes, of which at least Ny — 2fy 
are honest. Note that any two Ny — fy subsets of Ny have at 
least one honest node in common. Because of this, if a receipt 
was generated, at least one honest node’s ANNOUNCE will 
be processed by every honest node, and all honest VC nodes 
will obtain the corresponding vote code in these two steps; 
thus, they enter step 3 with an opinion of 1. In this case, 
binary consensus is guaranteed to deliver 1 as the resulting 
value (because all honest nodes share the same opinion), thus 
safeguarding our contract against the voters. In any case, step 
3 guarantees all VC nodes arrive at the same conclusion, on 
whether this ballot is voted or not. 

In the algorithm outlined above, the result from binary 
consensus is translated from 0/1 to a status of “not-voted” 
or a unique valid vote code, in steps 4-IV-B. The 5b case of 
this translation, in particular, requires additional justihcation. 
Assume, for example, that a voter submitted a valid vote code 
vCa, but a receipt was not generated before election end time. 
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In this case, an honest vote collector node VCi may not be 
aware of vca at step 3 , as steps IV-B-2 do not make 
any guarantees in this case. Thus, VCt may rightfully enter 
consensus with a value of 0. However, when honest nodes’ 
opinions are mixed, the consensus algorithm may produce any 
result. In case the result is 1, VCi will not possess the correct 
vote code vCa, and thus will not be able to translate the result 
properly. This is what our recovery sub-protocol is designed 
for. VCi will issue a RECOVER-REQUEST multicast, and 
we claim that another honest node, VCh exists that possesses 
vCa and replies with it. The reason for the existence of an 
honest VCh is straightforward and stems from the properties 
of the binary consensus problem dehnition. If all honest nodes 
enter binary consensus with the same opinion a, the result of 
any consensus algorithm is guaranteed to be a. Since we have 
an honest node VCi, that entered consensus with a value of 
0, but a result of 1 was produced, there has to exist another 
honest node VCh that entered consensus with an opinion of 
1. Since VCh is honest, it must possess vCa, along with 
the corresponding UCERT (as no other vote code vcb can 
be active at the same time for this ballot). Again, because 
VCh is honest, it will follow the protocol and reply with a 
well formed RECOVER-REPLY. Additionally, the existence 
of UCERT guarantees that any malicious replies can be safely 
identified and discarded. 

At the end of this algorithm, each node submits the resulting 
set of voted (serial-no, vote-code) tuples to each BB node, 
which concludes its operation for the specihc election. 

F. Voter 

We expect the voter, who has received a ballot from EA, 
to know the URLs of at least fv + 1 VC nodes. To vote, 
she picks one part of the ballot at random, selects the vote 
code representing her chosen option, and loops selecting a VC 
node at random and posting the vote code, until she receives a 
valid receipt. After the election, the voter can verify two things 
from the updated BB. Eirst, she can verify her cast vote code 
is included in the tally set. Second, she can verify that the 
unused part of her ballot, as “opened” at the BB, matches the 
copy she received before the election started. This step verifies 
that the vote codes are associated with the expected options 
as printed in the ballot. Finally, the voter can delegate both of 
these checks to an auditor, without sacrificing her privacy; this 
is because the cast vote code does not reveal her choice, and 
because the unused part of the ballot is completely unrelated 
to the used one. 

G. Bulletin Board 

A BB node is a pubic repository of election-specihc in¬ 
formation. By dehnition, it can be read via a public and 
anonymous channel. Writes, on the other hand, happen over 
an authenticated channel, implemented with PKI originating 
from the voting system. BB nodes are independent from each 
other; a BB node never directly contacts another BB node. 
Readers are expected to issue a read request to all BB nodes, 
and trust the reply that comes from the majority. Writers are 


Algorithm 1 Vote Collector algorithms 

1: procedure ON VOTE(serial-no, vote-code) from source: 

2: if SysTimeQ between start and end 

3: b :=locateBallot(serial-no) 

4: if 6.status == NotVoted 

5: I := ballot.VerifyVoteCode(vote-code) 

6: if / 7 ^ null 

1: 6. UCERT := {} > Uniqueness certificate 

8: sendAll(ENDORSE(serial-no, vote-code)) 

9: wait for — fv) valid replies, fill 6.UCERT 

10: 6.status := Pending 

11: 6. used-vc := vote-code 

12: b.\rs := {} > list of receipt shares 

13: sendAll(VOTE_P(serial-no, vote-code, /.share)) 

14: wait for {Nv — fv) VOTE_P messages, fill b.\vs 

15: 6.receipt := Rec(6.lrs) 

16: 6.status := Voted 

17: senc/(sorirce, 6.receipt) 

18: else if 6.status == Voted AND 6.used-vc == vote-code 

19: send (source, ballot.receipt) 

20: procedure ON VOTE_P(serial-no, vote-code, share, UCERT) from 
source: 

21: if UCERT is not valid 

22: return 

23: if SysTimeif) between start and end 

24: b :=locateBallot(serial-no) 

25: if 6.status == NotVoted 

26: I := ballot.VerifyVoteCode(vote-code) 

27: if / 7^ null 

28: 6.status := Pending 

29: 6.used-vc := vote-code 

30: 6.lrs.Append(share) 

31: sendAll(VOTE_P(serial-no, vote-code,/.share) ) 

32: else if 6.status == Voted AND b.used-vc == vote-code 

33: /).lrs.Append(share) 

34: if size(/).lrs) >= Nv — fv 

35: 6.receipt := Rec(/).lrs) 

36: 6.status := Voted 

37: function Ballot: :VERlFYVOTECODE(vote-code) 

38: for / = 1 to ballot_lines do 

39: if lines[/].hash == /i(vote-code||lines[/].salt) return / 

return null 


also expected to write to all BB nodes; their submissions are 
always verified, and explained in more detail below. 

After the setup phase, each BB node publishes its initial¬ 
ization data. During election hours, BB nodes remain inert. 
After the voting phase, each BB node receives from each VC 
node, the final vote-code set and the shares of msk. Once it 
receives /i; + 1 identical final vote code sets, it accepts and 
publishes the final vote code set. Once it receives Ny — fy 
valid key shares (again from VC nodes), it reconstructs the 
msk, decrypts all the encrypted vote codes in its initialization 
data, and publishes them. 

At this point, the cryptographic payloads corresponding to 
the cast vote codes are made available to the trustees. Trustees, 
in turn, read from the BB subsystem, perform their individual 
calculations and then write to the BBs; these writes are verified 
by the trustees keys, generated by the EA. Once enough 
trustees have posted valid data, the BB node combines them 
and publishes the final election result. 

We intentionally designed our BB nodes to be as simple 
as possible for the reader, refraining from using a Replicated 
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State Machine, which would require readers to run algorithm- 
specihc software. The robustness of BB nodes comes from 
controlling all write accesses to them. Writes from VC nodes 
are verified against their honest majority threshold. Further 
writes are allowed only from trustees, verihed by their keys. 

Finally, a reader of our BB nodes should post her read 
request to all nodes, and accept what the majority responds 
with (fb + 1 is enough). We acknowledge there might be 
temporary state divergence (between BB nodes), between the 
time a writer hnishes updating one BB node, and until he 
updates another. However, given our thresholds, this should 
be only momentary, alleviated with simple retries. Thus, if 
there is no reply backed by a clear majority, the reader should 
retry until there is such a reply. 

H. Trustees 

After the end of election, each trustee fetches all the election 
data from the BB subsystem and verifies the validity of the 
election data. For each ballot, there are two possible valid 
outcomes: i) one of the A/B parts are voted, ii) none of the 
A/B parts are voted. If both A/B parts of a ballot are marked 
as voted, then the ballot is considered as invalid and should 
be discarded. Similar, trustees also discard those ballots where 
more than maximum allowed commitments in an A/B part are 
marked as voted. In case (i), for each encoded option com¬ 
mitment in the voted part. Trustee^ submits its corresponding 
share of the opening of the commitment to the BB; for each 
encoded option commitment in the unused part. Trustee^ 
computes and posts the share of the hnal message of the 
corresponding zero knowledge proof, showing the validity of 
those commitments; meanwhile, those commitments marked 
as voted are collected to a tally set Etaiiy- In case (ii), for each 
encoded option commitment in both parts. Trustee^ submits 

its corresponding share of the opening of the commitment to 

ii') 

the BB. Finally, denote as Trustee^’s set of shares of 

option encoding commitment openings, corresponding to the 
commitments in Etaiiy Trustee^ computes the opening share 
for Esuni as T£ = ^ and then submits Ti to each BB 

node. 

I. Auditors 

Auditors are participants of our system who can verify the 
election process. The role of the auditor can be assumed by 
voters or any other party. After election end time, auditors read 
information from the BB and verify the correct execution of 
the election, by verifying the following: a) within each opened 
ballot, no two vote codes are the same; b) there are no two 
submitted vote codes associated with any single ballot part; 

c) within each ballot, no more than one part has been used; 

d) all the openings of the commitments are valid; e) all the 
zero-knowledge proofs that are associated with the used ballot 
parts are completed and valid; 

In case they received audit information (an unused ballot 
part and a cast vote code) from voters who wish to delegate 
verification, they can also verify: f) the submitted vote codes 
are consistent with the ones received from the voters; g) the 


openings of the unused ballot parts are consistent with the 
ones received from the voters. 

IV. Security of D-Demos 

In this Section, we describe at length the security properties 
that D-DEMOS achieves under the threat model described 
in Section III-C. Specifically, we show that our distributed 
system achieves liveness and safety, as well as end-to-end 
verifiability and voter privacy at the same level of [28]'. 

We use m, n to denote the number of options and vot¬ 
ers respectively. We denote by A the cryptographic security 
parameter and we write negl(A) to denote that a function is 
negligible in A. We assume the following security guarantees 
for the underlying cryptographic tools: 

1) The probability that an adversary running in A steps 
forges digital signatures is no more than negl(A). 

2) There exists a constant c < 1 s.t. the probability that 
an adversary running in 0(2^ ) steps breaks the hiding 
property of the option-encoding commitments is no more 
than negl(A). 

A. Liveness 

To prove the liveness our DBB guarantees, we assume (I) 
an upper bound 6 on the delay of the delivery of messages 
and (II) an upper bound A on the drift of all clocks (see Sec¬ 
tion III-C2). Furthermore, to express liveness rigorously, we 
formalize the behavior of honest voters regarding maximum 
waiting before vote resubmission as follows: 

Definition 1 ([d]-patience). Let V be an honest voter that 
submits her vote at some VC node when Clock[V] = T. We 
say that V is [d]-patient, when the following condition holds: If 
V does not obtain a receipt by the time that Clock[y] = T -fd, 
then she will blacklist this VC node and submit the same vote 
to another randomly selected VC node. 

Using Definition 1, we prove the liveness of our e-voting 
system in the following theorem: 

Theorem 1 (Liveness). Let A be an adversary against D- 
DEMOS under the model described in Section III-C, where 
assumptions 1,11 in Section III-C2 hold and A corrupts up to 
fv < Ny /3 VC nodes. Let Tcomp be the worst-case running 
time of any procedure run by the VC nodes and the voters 
respectively during the voting protocol Let Tend denote the 
election end time. Define 

dwait := {2.Ny 4)Tcomp + 12A -f Bd . 

Then, the following conditions hold: 

1) Every [T„ait]-pafienf voter that is engaged in the voting 
protocol by the time that Clock[U] = Tend —(/i; + l)-T„ait, 
will obtain a valid receipt. 

2) Every \T,^s\t\-patient voter that is engaged in the voting 
protocol by the time that Clock[U] = Tend — y ■ dwait. 

’in [28], the authors use the term voter privacy/receipt-freeness, but they 
actually refer to the same property. 
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where y S [fv], will obtain a valid receipt with more 
than 1 — 3“^ probability. 

Proof. Let L be a [Twait] -patient voter initialized by the 
adversary A when Clock = Clock[L] = T. We will compute 
an upper bound on the time required for an honest responder 
VC node to issue a receipt to V . This bound will be derived 
by the time upper bounds that correspond to each step of the 
voting protocol, as described in Sections III-E and III-F, taking 
also into account the A upper bound on clock drifts and the 
5 upper bound on message delivery. In Table I, we provide 
the advance of these upper bounds at the global clock and 
the internal clocks of V and VC, so that we illustrate the 
description of the computation described below. 

Upon initialization, U’s internal clock is synchronized with 
the global clock at time Clock = Clock[U] = T. After at 
most Tcomp steps, V submits her vote (serial-no, vote-code) at 
internal clock time; Clock[U] = T + Tcomp, hence at global 
clock time: Clock < T -t- A. 

Thus, VC will receive the vote of V at internal time 
Clock[yC'] < T + Tcomp + 2A + S. Then, VC performs at 
most Tcomp steps to verify the validity of the vote before it 
broadcasts its an ENDORSE request to the other VC nodes by 
global clock time Clock < T-|-Tcomp + 2A-|-(5-l-(Tcomp-l-A) = 
T -|- 2Tcomp + 3A -f 5. 

All the other honest VC nodes (Ny — fy — 1 in total) will 
receive VC’s ENDORSEMENT request by global clock time; 
Clock < T + 2Tcomp -b 3A + 26, which implies that the time 
at their internal clocks is at most T + 2Tcomp -b 4A -f 26. 
Upon receiving the request, all the honest VC nodes will 
verify if vote-code has never been endorsed before and if 
so, they respond with an ENDORSEMENT message after at 
most Tcomp steps. The global clock at that point is at most 
Clock = (T -f 2Tcomp + 4A -I- 26) -b Tcomp "b A = T -f 
3Tcomp -b 5A + 26. Therefore, VC will obtain the other honest 
VC nodes’ ENDORSE messages at most when Clock[yC'] = 
(T -f 3Tcomp + 5A -f 26) -\- A. 6 = T 3Tcomp -b 6A -f 3(5. 

In order to determine the uniqueness certihcate UCERT 
for U’s vote, VC has to verify up to Ny — 1 messages 
(as the fy malicious VC nodes may also send arbitrary 
messages). Since the message verihcation and the UCERT 
generation require (A^« — l)-Tcomp and Tcomp steps respectively 
, VC will broadcast its receipt share at global clock time 

Clock < (T-|-3Tcomp + 6A-(-35)-b(W„—l)-Tcomp-bTcomp + A = 

T -|- [Ny 3)Tcomp + 7A -f 36. 

All the other honest VC nodes will receive VC’s receipt 
share by global clock time; Clock < T + [Ny + 3)Tcomp + 
7A -1-4(5, which implies that the time at their internal clocks is 
at most T + [Ny + 3)Tcomp + 8A + 45. Then, they will verify 
VC’s share and broadcast their shares for V’s vote after at 
most Tcomp steps. The global clock at that point is no more 
than Clock = T -f [Ny + 3)Tcomp + 8A -f 45 -b (Tcomp + A) = 
T -f [Ny 4)Tcomp "b 9A -|- 45. 

Therefore, VC will obtain the other honest VC nodes’ 
shares at most when Clock[UC] = T + [Ny + 4)Tcomp + 
9A -f 45 -b (A -b 5) = T -f [Ny 4)Tcomp -b lOA -I- 55 and 


will process them in order to reconstruct the receipt for V. In 
order to collect Ny — fy — 1 receipt shares that are sufficient 
for reconstruction, VC may have to perform up to Ny — 1 
receipt-share verifications, as the fy malicious VC nodes may 
also send invalid messages. This verihcation requires at most 
[Ny — 1) • Tcomp Steps. Taking into account the Tcomp steps for 
the reconstruction process, we conclude that VC will hnish 
computation by global time 

Clock = T -(- [Ny 4)Tcomp + lOA -I- 55-b 

+ [Afy — l)Tcomp + Tcomp -b A = 

= T + [2Ny + 4)Tcomp + llA -f 55. 

Finally, V will obtain the receipt after at most 5 delay 
from the moment that VC hnishes computation. Taking into 
consideration the drift on U’s internal clock, we have that if 

V is honest and has not yet obtained a receipt by the time that 

Clock[U] = {T+ [2Ny + 4)Tcomp + llA -f 55) -b A -f 5 = 
= T -|- [2Ny + 4)Tcomp -b 12A + 66 = T + T^gjt, 

then, being [Twait]-patient, she can blacklist VC and resubmit 
her vote to another VC node. We will show that the latter 
fact implies conditions 1 and 2 in the statement of the theorem: 

Condition 1: since there are at most fy malicious VC nodes, 

V will certainly run into an honest VC node at her (/„ -f l)-th 
attempt (if reached). Therefore, if V is engaged in the voting 
protocol by the time that Clock[U] = Tend — [fv + 1) • T^ait, 
then she will obtain a receipt. 

Condition 2: if V has waited for more than j/ Twait time and 
has not yet received a receipt, then it has run at least y failed 

attempts in a row. At the j-th attempt, V has -A- -^ 

Ny — [j — 1) 

probability to randomly select one of the remaining /« — (j — 1) 
malicious VC nodes out of the Ny — [j — 1) non-blacklisted 
VC nodes. Thus, the probability that V runs at least y failed 
attempts in a row is 

fv — (j ~ 1) _ 1 ^ fv — (j ~ 4) o-y 

niv,-(j-i) -nsfy + i-u-i) 

Therefore, if V is engaged in the voting protocol by the time 
that Clock[U] = Tend — y ■ T^ait, then the probability that she 
will obtain a receipt is more than 1 — 3“^'. 

□ 

B. Safety 

Our safety theorem is stated in the form of a contract 
adhered by the VC subsystem. Namely, the following safety 
theorem proves the gurantee that the recorded-as-cast feedback 
of D-DEMOS provides for every honest voter that obtained a 
valid receipt at the voting protocol. 

Theorem 2 (Safety). Let A be an adversary against D- 
DEMOS under the model described in Section III-C that 
corrupts up to fy < Ny/3 VC nodes, up to fh < Nh/2 BB 
nodes and up to Nt — ht out-of Nt trustees. Then, every honest 
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Step 

1 Time upper bounds at each clock | 

Clock 

ClocklU] 

ciockiuq 

honest VC nodes’ clocks 

V is initialized 

T 

T 

T + A 

T +A 

V submits her vote to VC 

+ '^comp + ^ 

T + Tcomp 

T + Tcomp + 2A 

T + Tcomp + 2A 

VC receives V’s ballot 

T + Tcomp + A + (5 

T + Tcomp + 2A + 5 

T + Tcomp + 2A + 5 

T + Tcomp + 2A + 5 

VC verifies the validity of 
V’s ballot and broadcasts an 
ENDORSE message 

T + 2Tcomp + 3A + (5 

T + 2Tcomp “b 4A + S 

T + 2Tcomp + 2A + 5 

T + 2Tcomp + 4A + 5 

All the other honest VC 
nodes receive VC’s 
ENDORSE message 

T + 2Tcomp H“ 3A + 2(5 

T + 2Tcomp + 4A + 2(5 

T + 2Tcomp + 4A + 25 

T + 2Tcomp + 4A + 25 

All the other honest VC 
nodes verify the validity of 
the ENDORSE message and 
respond with an 
ENDORSEMENT message 

T + 3Tcomp H“ 3A + 25 

T + 3Tcomp + 6A + 25 

T + 3Tcomp + 6A + 25 

T + 3Tcomp + 4A + 5 

VC receives the 
ENDORSEMENT messages 
of all the other honest VC 
nodes 

T + 3Tcomp + 5A + 3(5 

T + 3Tcomp + 6A + 35 

T + 3Tcomp + 6A + 35 

T + 3Tcomp + 6A + 35 

VC verifies the validity of all 
the Nv — 1 received messages 
until it obtains Ny — fy valid 
ENDORSEMENT messages 

T + {Ny + 2)Tcomp + 

7A + 3^ 

T + {Ny + 2)Tcomp + 
8A + 35 

T + {Ny + 2)Tcomp + 
6A + 35 

T + {Ny + 2)Tcomp + 

8A + 35 

VC forms UCERT certificate 
and broadcsts its share and 
UCERT 

T + {Ny + 3)T’comp + 

7A + 3^ 

T + {Ny + 3)Tcomp + 
8A + 35 

T + {Ny + 3)Tcomp + 
6A + 35 

T + {Ny + 3)Tcomp + 

8A + 35 

All the other honest VC 
nodes receive VC’s broadcast 
share and UCERT 

T + {Ny + 3)Tcomp + 
7A-\-45 

T + {Ny + 3)Tcomp + 
8A + 45 

T + {Ny + 3)Tcomp + 
8A + 45 

T + {Ny + 3)Tcomp + 

8A + 45 

All the other honest VC 
nodes verify the validity of 
UCERT and V’s share and 
broadcast their shares 

T' + {Ny + 4)Tcomp + 
9A + 45 

T + {Ny + 4)Tcomp + 
lOA + 45 

T + {Ny + 4)Tcomp + 
lOA + 45 

T + {Ny + 4)Tcomp + 

8A + 45 

VC receives all the other 
honest VC nodes’ shares 

T + {Ny + 4)T’comp + 
9A + 5(5 

T + {Ny + 4)Tcomp + 
lOA + 55 

T + {Ny + 4)Tcomp + 
lOA + 55 

T + {Ny + 4)Tcomp + 
lOA + 55 

VC verifies the validity of all 
the Ny — 1 received 
messages until it obtains 

Ny — fy valid shares 

T + {2Ny + 3)Tcomp + 
llA + 5(5 

T + {2Ny + 3)Tcomp + 
12A + 55 

T + (2A^^; + 3)Tcomp + 
lOA + 55 

T + (2A^^ + 3)Tcomp + 
12A + 55 

VC reconstructs and V’s 
receipt and sends it to V 

T + {2Ny + 4)Tcomp + 
llA + 5(5 

T + {2Ny + 4)Tcomp + 
12A + 55 

T + (2A^^; + 4)Tcomp + 
lOA + 55 

T + {2Ny + 4)Tcomp + 
12A + 55 

V obtains her receipt 

T + {2Ny + 4)Tcomp + 
llA + 6(5 

T + {2Ny + 4)Tcomp + 
12A + 65 

T + (2V^; + 4)Tcomp + 
12A + 65 

T + {2Ny + 4)Tcomp + 
12A + 65 


Table I 

Time upper bounds at Clock, Clock[y], Clock[yc] and other honest VC nodes’ clocks at each step of the interaction of V with 

RESPONDER VC. THE GRAYED CELLS INDICATE THE REFERENCE POINT OF THE CLOCK DRIFTS AT EACH STEP. 


voter who receives a valid receipt from a VC node, is assured 
her vote will be published on the honest BB nodes and included 
in the election tally, with probability at least 

1 - negl(A) - . 

Proof. Let V be an honest voter. Then, A' strategies on 
attacking safety (i.e. provide a valid receipt to V but force 
the VC subsystem to discard L’s ballot), is captured by either 
one of the two following cases: 

Case 1. Produce the receipt without being involved in a complete 
interaction with the VC subsystem (i.e. with at least fv + 1 
honest VC nodes). 

Case 2. Provide a properly reconstructed receipt via a complete 
interaction with the VC subsystem. 

Let El (resp. E 2 ) be the event that Case 1 (resp. Case 2) 
happens. We study both cases: 


Case 1. In this case, A must produce a receipt that matches 
V’s ballot with less than Ny — /„ shares. A may achieve this 
by either one of the following ways: 

(i). A attempts to guess the valid receipt; If A succeeds, then 
it can force the VC subsystem to consider L’s ballot not 
voted as no valid UCERT certificate will be generated 
for V’s ballot. Since there are at most /„ malicious VC 
nodes, the adversary has at most /„ attempts to guess the 
receipt. Moreover, the receipt is a randomly generated 
64-bit string, so after i attempts, A has to guess among 
(2®"* — i) possible choices. Therefore, the probability 
succeeds is no more than 

^ - < - — - 

^ 2-64 _ i - 2-64 _ 
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(ii) . A attempts to reconstruct the receipt using all the 

malicious VC nodes’ receipt shares. These are at most 
/„, so by the information theoretic security of the 
(iV^ — fv, NyYWSS scheme the probability of success 
for A is no better than above {A can only perform a 
random guess). 

(iii) . A attempts to produce fake UCERT certificates by 

forging digital signatures of other nodes. By the security 
of the digital signature scheme, this attack has negl(A) 
success probability. 

By the above, we have that 

Pr[Al wins \Ei] < + negl(A) . (1) 

Case 2. In this case, by the security arguments stated in 
Section III-E (steps -), every honest VC node will include the 
vote of V in the set of voted tuples. This is because a) it locally 
knows the valid (certified) vote-code for V accompanied 
by UCERT or b) it has obtained the valid vote-code via a 
RECOVER-REQUEST message. Recall that unless there are 
fake certificates (which happens with negligible probability) 
there can be only one valid vote-code for V. 

Consequently, all the honest VC nodes will forward the 
agreed set of votes (hence, also U’s vote) to the BB nodes. 
By the fault tolerance threshold for the BB subsystem, the fi, 
honest BB nodes will publish U’s vote. Einally, the ht out-of 
Nt honest trustees will read U’s vote from the majority of BB 
nodes and include it in the election tally. Thus, we have that 

Pr[Al wins |i? 2 ] = negl(A) . (2) 

By Eq. (1),(2), if U obtains a valid receipt, then his vote will be 
published on the honest BB nodes and included in the election 
tally, with probability at least 

1 - negl(A) - . 

□ 

Theorem 4 provides guarantee that the honest voter’s vote 
will be recorded-as-cast by the system on an individual level. 
Using Theorem 4, we prove the following corollary about the 
“universal” safety of the receipt-based feedback mechanism of 
D-DEMOS. 


C. End-to-end Verifiability 

We adopt the end-to-end (E2E) verifiability definition 
in [28], modified accordingly to our setting. Namely, we 
encode the options set {optiori]^,..., option^}, where the 
encoding of optiorij is an m-bit string which is only in the 
Uth position. Let F be the election evaluation function such 
that F(optionj^ ..., optiorij^) is equal to an m-vector whose 
Uth location is equal to the number of times option^ was voted. 
Then, we use the metric di(-, •) derived by the 1-norm, || • ||i 
scaled to half, i.e., 

di : Z™ X Z™ —^ K 

{wM) 

to measure the success probability of the adversary with 
respect to the amount of tally deviation d and the number 
of voters that perform audit 6. 

We model end-to-end verifiability via a game between a 
challenger and an adversary. The adversary starts by selecting 
the identities of the voters, options, VC nodes, BB nodes and 
trustee nodes identities for given parameters n,m, Ny, Ni,,Nt. 
In [28], the adversary corrupts the EA which manages the 
elestion setup, the vote collection, and the tally computation. 
Analogolously, the adversary in D-DEMOS now fully controls 
the EA, all the trustees, and all the VC nodes. Moreover, [28] 
assumes a consistent BB. In our model, we guarantee a this 
BB by restricting the adversary to statically corrupt a minority 
of the BB nodes. 

At the voting phase, it manages the vote casting of every 
voter. Eor each voter, the adversary may choose to corrupt 
her or to allow the challenger to play on her behalf. In the 
second case, the adversary provides the option selection that 
the honest voter will voter. The adversary finally posts the 
election transcript to the BB. Einally, we make use of a vote 
extractor algorithm £ (not necessarily running in polynomial¬ 
time) that extracts the non-honestly cast votes. The adversary 
will win the game provided that there is a subset of 9 honest 
voters that audit the result successfully but the deviation of 
the tally is bigger than d; the adversary will also win in case 
the vote extractor fails to produce the option selection of the 
dishonest voters but still, 9 honest voters verify correctly. The 
attack game is specified in detail in Eigure 2. 


Corollary 1. Let n be the number of voters. Let A be an 
adversary against D-DEMOS under the model described in 
Section III-C that corrupts up to fy < Ny /3 VC nodes, up to 
fb < Nb/2 BB nodes and up to Nt — ht out-of Nt trustees. 
Then, the probability that A achieves in excluding the vote of 
at least one honest voter that obtained a valid receipt from 
the election tally is no more than 


nfy 


+ negl(A) 


2-64 _ 

Proof. The proof is straightforward by taking a union bound 
on the probability of successful attack on the safety of every 

fv 

single honest voter and the upper bound —— -f negl(A) 

□ 


2-64 _ 

on A’s success probability derived by Theorem 4. 


Definition 2 (E2E Verifiability). Let 0 < e < 1 and 
n, TO, Ny, Nb, Nt (zNpolynomial in A with 9 < n. Let If be an 
e-voting system with n voters, Ny VC nodes, Nb BB nodes and 
Nt trustees. We say that If achieves end-to-end verifiability 
with error e, w.r.t. the election function F, a number of 9 
honest successfull voters and tally deviation d if there exists 
a (not necessarily polynomial-time) vote extractor £ such that 
for any PPT adversary A it holds that 

Pr[G±^f/{l\m,n,Ny,Nb,Nt) = 1] < e. 


Theorem 3. Let n, to, Ny, Nb, Nt,9,d € N where \ <9 <n. 
Then, D-DEMOS run with n voters, m options, Ny VC nodes, 
Nb BB nodes and Nt trustees achieves end-to-end with error 
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E2E Verifiability Game G^e^ver^(l^: Nb, Nt) 

1) A on input l^,n,m, Ny, Ni,, Nt, chooses a list 

of options {optioH]^,option^}, a set of voters 
V = {Vi,...,Vn}, a set of VC nodes VC = 
{VCi,..., VCjv„}, a set of BB nodes 23® = 

{BBi,..., BBjVfc}, and a set of trustees T = 
{Ti,..., TjVj}- It provides the challenger Ch with all 
the above sets. 

Throughout the game, A controls the EA, all the VC 
nodes and all the trustees. In addition, A may corrupt 
a fixed set of up to BB nodes, denoted by 'B'Bsucc- On 
the other hand, Ch plays the role of all the honest BB 
nodes. 

2) A and C engage in an interaction where A schedules 
the vote casting executions of all voters. Eor each 
voter V^, A can either completely control the voter 
or allow C to operate on V^’s behalf, in which case 
A provides C with an option selection optionThen, 
C casts a vote for optionand, provided the voting 
execution terminates successfully, C obtains the audit 
information audits on behalf of Vg. 

Let Vsucc be the set of honest voters (i.e., those 
controlled by C) that terminated successfully. 

3) Einally, A posts a version of the election transcript 
infoj in every honest BB node BBj ^ ®®corr- 

The game returns a bit which is 1 if and only if the 
following conditions hold true; 

1. |®®corr| < (i-e., the majority of the BB nodes 

remain honest). 

2. VBBj, BBj/ ^ ®®corr : infoj = infoj/ := info (i.e, the 
data posted in all honest BB nodes are identical). 

3. IVsuccI > 6* (i-c., at least Q honest voters terminated). 

4. \lt C [n] : if G Vsucc then Vi verifies succesfull, 
when given (info, audits) as input. 

and either one of the following two conditions; 

5.a. if _L 7^ (option,Jy^^v,„„ ^ £(info, {audit4y,ev,„„) 
then 

di(Result(info),F(optionj^ ... ,optionj^)) > d, 

5.b. _L ^ £(info, {audit4y,ev,„„)- 


Figure 2. The E2EVerifiability Game between the challenger C and the 
adversary A using the vote extractor £. 


2 ® + 2 w.r.t. the election function F, a number of 9 honest 
successfull voters and tally deviation d. 

Proof Without loss of generality we can assume that every 
party can read consistently the data published in the majority 
of the BB nodes, as otherwise the adversary fails to satisfy 
either conditions 1 or 2 of the E2E verifiability game. 

We first construct a vote extractor £ for D-DEMOS as 
follows; £ takes input as the election transcript, info and 
a set of audit information {audits. If info is not 


meaningful, then £ outputs _L. Let B < |V| be the num¬ 
ber of different serial numbers that appear in {audiG}y^g.y. 
Otherwise, £ (arbitrarily) arranges the voters in 14 G Vjucc 
and the serial numbers not included in {audit^j^^gy^ as 
(V/)^g[„_|v,,„|] and (tagfrespectively. Next, for 
every £ G [n — |Vsucc|], £ extracts option^^ by brute force 
opening and decrypting (in superpolynomial time) all the 
committed and encrypted BB data, or sets option^^ as the zero 
vector, in case Vfs vote is not published in the BB. Einally, 
£ outputs (option, 


We will prove the E2E verifiability of D-DEMOS based 
on £. Assume an adversary A that wins the game 
,m,n,Ny,Nt„Nt). Namely, A breaks E2E ver¬ 
ifiability by allowing at least 9 honest successful voters and 
achieving tally deviation d. 

Let Z be the event that A attacks by making at least one of 
the option-encoding commitments associated with some cast 
vote-code invalid (i.e., it is in tally set Etaiiy but it is not 
a commitment to some candidate encoding). Since there are 
at least 9 honest and succesful voters, the min-entropy of the 
collected voters’ coins is at least 9. By min-entropy Schwartz- 
Zippel Lemma [28, Lemma 1] and following the lines of [28, 
Theorem 2], we have that when the challenge is extracted 
from voters’ coins of min-entropy 9, the verification of the 
Chaum-Pedersen zero-knowledge proofs used in D-DEMOS 
for committed ballot correctness in the BB is sound except 
for some probability error 2“®. Therefore, since there is at 
least one honest voter that verifies, we have that 


(l^ m, n, iV„, iV*) = 1 A Z] < 2-® . (3) 


Now assume that Z does not occur. In this case, the vote 
extractor £ will output the indended adversarial votes up to 
permutation. Thus, the deviation from the intended result that 
A achieves, derives only by miscounting the honest votes. This 
may be achieved by A in two different possible ways; 

• Modification attacks. When committing to the infor¬ 
mation of some honest voter’s ballot part A changes the 
vote-code and option correspondence that is printed in 
the ballot. This attack will be detected if the voter does 
chooses to audit with the modified ballot part (it uses the 
other part to vote). The maximum deviation achieved by 
this attack is 1 (the vote will count for another candidate). 

• Clash attacks. A provides y honest voters with ballots 
that have the same serial number, so that the adversary 
can inject y — 1 votes of his preference in the y — 1 
“empty” audit locations in the BB. This attack is suc¬ 
cessful only if all the y voters verify the same ballot on 
the BB and hence miss the injected votes that produce 
the tally deviation. The maximum deviation achieved by 
this attack is y — 1. 

We stress that if Z does not occur, then the above two attacks 
are the only meaningful^ for A to follow. Indeed, if (i) all 


^By meaningful we mean that the attack is not trivially detected. For 
example, the adversary may post malformed information in the BB nodes 
but if so, it will certainly fail at verification. 
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zero knowledge proofs are valid, (ii) all the honest voters are 
pointed to a unique audit BB location indexed by the serial 
number on their ballots, and (iii) the the committed in this 
BB location information matches the vote-code and option 
association in the voters’ unused ballot parts, then by the 
binding property of the commitments, all the tally computed 
by the commitments included in Etaiiy will decrypt to the 
actual intended result. 

Since the honest voters choose the used ballot parts at 
random, the success probability of x deviation via the modifi¬ 
cation attack is (1/2)^. In addition, the success probability to 
clash y honest voters is (1/2)^“^ (all y honest voters choose 
the same version to vote). As a result, by combinations of 
modification and clash attacks, A’s success probability reduces 
by a factor 1/2 for every unit increase of tally deviation. 
Therefore, the upper bound of the success probability of A 
when Z does not occur is 

Pr[Gf 2 ;^e?(l^ m, n, N,,Nb, Nt) = 1 \ -Z] < 2"'' . (4) 

By Eq. (3), (4), we have that 

Pr[Gf 2 ;^e?(l^ m, n, N,, m, Nt) = 1] < 2-® + 2“'' . 

□ 

D. Voter Privacy 

Our privacy definition is extends the one used in [28] to 
the distributed setting of D-DEMOS. Similarly, voter privacy 
is defined via a Voter Privacy game as depicted in Eigure 3. 
The game, denoted as ’’^(1'^, n, m, Ny, Nb, Nt), is played 
between an adversary and a challenger, and we say the 
adversary wins the game if and only if it returns 1. During 
the game, the adversary A first chooses a list of options, a set 
of voters, a set of VC nodes, a set of BB nodes, and a set 
of trustees, of size Tn,n, Ny, Nb, Nt respectively. We require 
that the EA is destroyed after setup, whereas the adversary 
may control the entire VC subsystem, up to fb < Nb/2 BB 
nodes and up to ft < Nt/3 trustees. The adversary may 
also corrupt up to (p voters. The adversary then instructs 
the honest voters to vote according to either one of two 
alternative ways under the restriction that election tally is the 
same for both ways. The system achieves voter privacy if the 
adversary cannot distinguish which alternative was followed 
by the honest voters. 

Definition 3 (Voter Privacy). Let 0 < e < 1 and 

n,m, Ny, Nb, Nt G N. Let II be an e-voting system with n 
voters, m options awith n voters, Ny VC nodes, Nb BB nodes 
and Nt trustees w.r.t. the election function /. We say that II 
achieves voter privacy with error e for at most f corrupted 
voters, if there is a PPT voter simulator § such that for any 
PPT adversary A: 

I Vr[G^^’’^{l\n,m,Ny,Nb,Nt) = 1] - 1/2| = negl(A). 

Theorem 4. Assume there exists a constant c, 0 < c < 1 such 
that for any 2^ -time adversary A, the advantage of breaking 
the hiding property of the underlying commitment scheme is 


Voter privacy Game n, m, Ny, Nb, Nt) 

1) A on input l^,n,m,k, chooses a list of options 

y = {Pi,..., Pm}, a set of voters V = {Vi,..., 14}, 
a set of trustees T = {ri,...,I4}, a set of 

VC nodes {VCi,..., VC^v^} a set of BB nodes 
{BBi,...,BB 7 Vt}- It provides Ch with all the above 
sets. 

Throughout the game, A corrupts all the VC nodes a 
fixed set of fb < Nb/3 BB nodes and a fixed set of 
ft < Nt/3 trustees. On the other hand, Ch plays the 
role of the EA and all the non-corrupted nodes. 

2) Ch engages with A to prepare the election following 
the Election Authority protocol. 

3) After that, Ch chooses a bit value h G {0,1}. 

4) The adversary A and the challenger Ch engage in an 
interaction where A schedules the voters which may 
run concurrently. Eor each voter G V, the adversary 
chooses whether is corrupted: 

• If V) is corrupted, then Ch provides the credential 
Si to A, who will play the role of Vi to cast the 
ballot. 

• If is not corrupted, then A provides two option 
selections (option/, option}) to the challenger Ch 
which operates on V^’s behalf, voting for option 
option/. The adversary A is allowed to observe 
the network trace. After cast a ballot, the chal¬ 
lenger Ch provides to A: (i) the audit information 
ai that Vi obtains from the protocol, and (ii) 
if b = 0 . the current view of the internal state of 
the voter Vi, viewi, that the challenger obtains 
during voting, or if 6 = 1 . a simulated view of 
the internal state of Vi produced by §{viewi). 

5) The adversary A and the challenger Ch produce the 
election tally, running the Trustee protocol. A is al¬ 
lowed to observe the network trace of that protocol. 

6) Einally, A using all information collected above (in¬ 
cluding the contents of the BB) outputs a bit 6*. 

Denote the set of corrupted voters as Vcorr and the set of 
honest voters as V = V \ Vcorr- The game returns a bit 
which is 1 if and only if the following hold true: 

(i) . b = b* (i.e., the adversary guesses b correctly). 

(ii) . I Vcorr I 4 f (i-C-r the number of corrupted voters is 

bounded by f). 

(iii) . /((option/)^^g.^) = /((option})^^g.^) (i.e., the elec¬ 

tion result w.r.t. the set of voters in V does not leak 

b). 


Figure 3. The Voter privacy Game between the adversary A and the challenger 
Ch using the simuator S. 

Advhide(-^) = negl(A). Let f for any constant c' < a 

Then, D-DEMOS run with n voters, m options, Ny VC nodes, 
Nb BB nodes and Nt trustees achieves voter privacy for at 
most <j) corrupted voters. 
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Proof. To prove voter privacy, we explicitly construct a sim¬ 
ulator § such that we can convert any adversary A who 
can win the privacy game n, m, fc) with a non- 

negligible probability to an adversary 'B who can break the 
hiding assumption of the underlying commitment scheme 
within polyiX) ■ << time. 

Note that the challenger Ch is maintaining a coin b € {0,1} 
and always uses the option option^ to cast the honest voters’ 
ballots. When n — f < 2, the simulator § simply outputs the 
real voters’ views. When n — (f> > 2, consider the following 
simulator §. At the beginning of the experiment, § flips a 
coin h' -(r- {0,1}. For each honest voter Vi, § switches the 
vote-codes for option option^ and option^ . Due to full VC 
corruption, A learns all the vote-codes. However, it does not 
help the adversary to disdinguish the simulated view from real 
view as the simulator only permutes vote-codes. Moreover, 
we can show that if A distinguishes the alternative followed 
by honest votes, then we can construct an algorithm 2? that 
invokes A and simulates an election execution where it guesses 

(i) the corrupted voters’ coins (in 2"^ expected attempts) and 

(ii) the election tally (in (n + 1)"* expected attempts). Thus, 

23 finishes a compete simulation with high probability running 
in n?{n + l)"*-2‘^ = 0(2^° ) steps. Namely, 23 can replace all 
the commitments on the BB to commitments of 0, except for 
the commitments in one honest voter’s ballot, which commits 
to the guessed tally result. By exploiting the distinguishing 
advantage of A, 23 can break the hiding property of the option¬ 
encoding commitment scheme in 0(2^° ) = o(2^°) steps, thus 
leading to contradiction. □ 

V. Implementation and evaluation 
Implementation. We implement the Election Authority com¬ 
ponent of our system as a standalone C-n- application, and all 
other components in Java. Whenever we store data structures 
on disk, or transmit them over the wire, we use Google 
Protocol Buffers [2] to encode and decode them efficiently. We 
use the MIRACL library [4] for elliptic-curve cryptographic 
operations. In all applications requiring a database, we use the 
PostgreSQL relational database system [6]. 

We build an asynchronous communications stack (ACS) on 
top of Java, using Netty [5] and the asynchronous PostgreSQL 
driver from [1], using TLS based authenticated channels for 
inter-node communication, and a public HTTP channel for 
public access. This infrastructure uses connection-oriented 
sockets, but allows the applications running on the upper 
layers to operate in a message-oriented fashion. We use this 
infrastructure to implement VC and BB nodes. We implement 
Bracha’s Binary Consensus directly on top of the ACS, and 
we use that to implement our Vote Set Consensus algorithm. 
We introduce a version of Binary Consensus that operates 
in batches of arbitrary size; this way, we achieve greater 
network efficiency. We implement “verifiable secret sharing 
with honest dealer”, by utilizing Shamir’s Secret Share library 
implementation [7], and having the EA sign each share. 

Web browser replicated service reader. Our choice to model 
the Bulletin Board as a replicated service of non-cooperating 


nodes puts the burden of response verification on the reader 
of the service; a human reader is expected to manually issue 
a read request to all nodes, then compare the responses and 
pick the one posted by the majority of nodes. To alleviate 
this burden, we implement a web browser extension which 
automates this task, as an extension for Mozilla Eirefox. The 
user sets up the list of URLs for the replicated service. The 
add-on 1) intercepts any HTTP request towards any of these 
URLs, 2) issues the same request to the rest of the nodes, and 
3) captures the responses, compares them in binary form, and 
routes the response coming from the majority, as a response 
to the original request posted by the user. Majority is defined 
by the number of defined URL prefixes; for 3 such URLs, the 
first 2 equal replies suffice. 

With the above approach, the user never sees a wrong reply, 
as it is filtered out by the extension. Also note this process 
will be repeated for all dependencies of the initial web page 
(images, scripts, CSS), as long at they come from the same 
source (with the same URL prefix), verifying the complete 
user visual experience in the browser. 

Evaluation. We experimentally evaluate the performance of 
our voting system, focusing mostly on our vote collection 
algorithm, which is the most performance critical part. We 
conduct our experiments using a cluster of 12 machines, 
connected over a Gigabit Ethernet switch. The first 4 are 
equipped with Hexa-core Intel Xeon E5-2420 @ 1.90GHz, 
16GB RAM, and one 1TB SATA disk, running CentOS 7 
Linux, and we use them to run our VC nodes. The remaining 
8 comprise dual Intel(R) Xeon(TM) CPUs @ 2.80GHz, with 
4GB of main memory, and two 50GB disks, running CentOS 
6 Linux, and we use them as clients. 

We implement a multi-threaded voting client to simulate 
concurrency. It starts the requested number of threads, each of 
which loads its corresponding ballots from disk and waits for 
a signal to start; from then on, the thread enters a loop where 
it picks one VC node and vote code at random, requests the 
voting page from the selected VC (HTTP GET), submits its 
vote (HTTP POST), and waits for the reply (receipt). This 
simulates multiple concurrent voters casting their votes in 
parallel, and gives an understanding of the behavior of the 
system under the corresponding load. 

We employ the PostgreSQL RDBMS [6] to store all VC 
initialization data from the EA. We start off by demonstrating 
our system’s capability of handling large-scale elections. To 
this end, we generate election data for referendums, i.e., 
m = 2, and vary the total number of ballots n from 50 million 
to 250 million (note the 2012 US voting population size was 
235 million). We fix the number of concurrent clients to 400 
and cast a total of 200,000 ballots, which are enough for our 
system to reach its steady-state operation. Ligure 5a shows the 
throughput of the system declines slowly, even with a five-fold 
increase in the number of eligible voters. 

In our second experiment, we explore the effect of m, 
i.e., the number of election options, on system performance. 
We vary the number of options from TO = 2tOTO=10. 
Each election has a total of n = 200, 000 ballots which we 
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Figure 4. Latency (4a, 4d) and throughput graphs (4b, 4e) of the vote collection algorithm vs. the number of VC nodes. Figures (4c and 4f) illustrate 
throughput versus the number of concurrent clients. First row illustrates LAN setting plots. Second row illustrates WAN setting plots. Election parameters are 
n = 200,000 and m = 4. 
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Figure 5. Throughput graphs of the vote collection phase versus the number of total election ballots n (5a) and the number of total election options m (5b). 
A total of 200,000 ballots were cast by 400 concurrent clients on 4 VC nodes. Figure 5c illustrates the duration of all system phases. Results depicted are for 
4 VCs, n = 200,000 and m = 4. All these plots are for disk based experiments. 


spread evenly across 400 concurrent clients. As illustrated in 
Figure 5b, our vote collection protocol manages to deliver 
approximately the same throughput regardless of the value of 
TO. Notice that the only extra overhead to induces during vote 
collection, is the increase in the number of hash verifications 
during vote code validation, as there are more vote codes per 
ballot. 

Next, we evaluate the scalability of our vote collection pro¬ 
tocol by varying the number of vote collectors and concurrent 
clients. We eliminate the database, by caching the election data 
in memory and servicing voters from the cache, to measure 


the net communication and processing costs of our voting 
protocol. We vary the number of VC nodes from 4 to 16, 
and distribute them across the 4 physical machines. Note that, 
co-located nodes are unable to produce vote receipts via local 
messages only, since the Ny — fy threshold cannot be satisfied, 
i.e., cross-machine communication is still the dominant factor 
in receipt generation. For election data, we use the dataset with 
n = 200,000 ballots and to = 4 options. 

In Figures 4a and 4b, we plot the average response time 
and throughput of our vote collection protocol, versus the 
number of vote collectors, under various concurrent client 
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scenarios. Results illustrate an almost linear increase in the 
client-perceived latency, for all concurrency scenarios, up to 
13 VC nodes. From this point on, when four logical VC nodes 
are placed on a single physical machine, we notice a non-linear 
increase in latency. We attribute this to the overloading of the 
memory bus, a resource shared among all processors of the 
system, which services all (in-memory) database operations. 

In terms of overall system throughput, however, the penalty 
of tolerating extra failures, i.e., increasing the number of 
vote collectors, manifests early on. We notice an almost 50% 
decline in system throughput from 4 to 7 VC nodes. However, 
further increases in the number of vote collectors lead to a 
much smoother, linear decrease. We repeat the same exper¬ 
iment by emulating a WAN environment using netem [27], 
a network emulator for Linux. We inject a uniform latency 
of 25ms (typical for US coast-to-coast communication [3]) 
for each network packet exchanged between vote collector 
nodes, and present our results in Figures 4d and 4e. A simple 
comparison between LAN and WAN plots illustrates our 
system manages to deliver the same level of throughput and 
average response time, regardless of the increased intra-VC 
communication latency. Finally, in Figures 4c and 4f, we plot 
system throughput versus the number of concurrent clients, in 
LAN and WAN settings respectively. Results show our system 
has the nice property of delivering nearly constant throughput, 
regardless of the incoming request load, for a given number 
of VC nodes. 

Finally, in Figure 5c, we illustrate a breakdown of the 
duration of each phase of the complete voting system (D- 
DEMOS), versus the total number of ballots cast. We assume 
immediate phase succession, i.e., the vote collection phase 
ends when all votes have been cast, at which point the vote 
set consensus phase starts, and so on. The “Push to BB 
and encrypted tally” phase is the time it takes for the vote 
collectors to push the final vote code set to the BB nodes, 
including all actions necessary by the BB to calculate and 
publish the encrypted result. The “Publish result” phase is the 
time it takes for Trustees to calculate and push their share 
of the opening of the hnal tally to the BB, and for the BB to 
publish the hnal tally. Note that, in most voting procedures, the 
vote collection phase would in reality last several hours and 
even days as stipulated by national law (see Estonia voting 
system). Thus, looking only at the post-election phases of the 
system, we see that the time it takes to publish the hnal tally 
on the BB is quite fast. 

Overall, although we introduced Byzantine Eault Tolerance 
across all phases of a voting system (besides setup), we 
demonstrate it achieves high performance, enough to run real- 
life elections of large electorate bodies. 

VI. Conclusion and future work 

We have presented the world’s hrst complete, state-of- 
the-art, end-to-end verihable, distributed voting system with 
no single point of failure besides setup. The system allows 
voters to verify their vote was tallied-as-intended without the 
assistance of special software or trusted devices, and external 


auditors to verify the correctness of the election process. 
Additionally, the system allows voters to delegate auditing 
to a third party auditor, without sacrihcing their privacy. 
We provided a model and security analysis of our voting 
system. Einally, we implemented a prototype of the integrated 
system, measured its performance and demonstrated its ability 
to handle large scale elections. 

As future work, we plan to expand our system to k-out-of-m 
elections. 
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